Nowadays, software is usually deployed in a complex environment. For example, a new software needs to be deployed in an environment where it must co-exist with other software or deployed across heterogeneous platforms (such as different operating systems). During the deployment, the installation of this new software is prone to failure due to, for example, complicated dependent relationships with other software and exclusive relationships with other software.
Refer to the following two situations:
1. After Globus® toolkit 3* (* indicates this and subsequent terms may be trademarks of the respective owners) released on JVM* (Java™ Virtual Machine*) 1.4.0, the Sun® Corporation released JVM 1.4.2. Therefore, the Globus® toolkit 3 needs a patch in order to run on the new JVM 1.4.2. However, during the installation of Globus® toolkit 3, the installer thereof cannot automatically resolve the patch problem. Thus, Globus® toolkit 3 is prone to failure when running on JVM 1.4.2. Only after a user resorts to a technical support website, will he(she) know that the Globus® toolkit 3 needs a patch in order to run on JVM 1.4.2.
2. To install DB2® on Linux®, a parameter for the kernel should be set. If the deployer ignores it, failure will occur during the installation of DB2® on Linux®.
A software installer is an executable software package to install a piece of software on a specific operating system. Software installers are always written by scripts and compiled to executable binary files. Examples of tools for making software installers include, but are not limited to:
For Windows® operating systems: Install shield*, Install suite*, and Windows® installer*;
For Linux® operating systems: RPM* (Redhat® Package Manager*); and
For TPM* (Tivoli® Provisioning Manager*, a software product of IBM®): Workflow*.
A software installer generally includes three parts: a dependency and conflict checking part for, for example, checking prerequisites and platform consistency; a software package installing part for, for example, unpacking software, copying the software to a right place, and registering COM (component object model) component; and a software configuring part for, for example, writing some configuration parameters to a configuration file.
In other words, the process of installing software generally includes three phases, i.e. a dependency and conflict checking phase, a software package installing phase, and a software configuring phase.
For the existing software installers made by using tools, like Install shield, RPM or TPM workflow, scripts thereof are packaged and compiled once into executable files. Therefore, the existing software installers are static.
Generally, after a new piece of software has been shipped, it will be installed in an environment in which various other software has been installed and in which various shipped software is to be installed. Therefore, before the shipment of a new piece of software, all conflicts between the software and other shipped existing and expected software in the same environment can be checked. In other words, during the installation of a new piece of software, the software installer thereof can check conflicts between the new piece of software and other shipped existing and expected software in the environment.
However, after the shipment of the new piece of software, it is impossible for the software installer to check conflicts between the new piece of software and other software which is to be shipped after the shipment of the new piece of software.
Additionally, when coding the software installer of the software, the programmer can hardly predict what problems will occur in future installation.
Therefore, failure is likely to occur during either the installing of the software using a static software installer or the running of the software. To resolve the failure, deployers or users have to search manuals or websites providing technical support to find some ways out.
Currently, there are many websites or symptom databases for providing technical support. These websites or databases always have the up-to-date solutions to these problems. However, users need much specific knowledge to understand solutions from the websites or databases.
Currently, in the case that software is installed by using the existing static software installer, when installation fails, the failure can hardly be resolved automatically.
Therefore, the existing software installer cannot meet the following deployment requirements:
1. Requirement from the Software Provider: after software is shipped, the software installer needs to be updated. For example, the software installer is required to install a latest patch of the software during the existing installation flow so as to provide more functions;
2. Requirement from the Solution Developer: the software installer needs to automatically change some configurations in relevant configuration files for a specific solution; and
3. Requirement from the Operator of technical support or software symptom management: the software installer needs to automatically resolve some installation problems based on a relevant symptom database, for example, resolve conflicts with other software which is to be shipped after the shipment of the software, i.e. automatically check and resolve conflicts.